De l'alerte publique à l'alerte interne : tweets, comptes Microsoft et échange Skype du 19 décembre 2016📋

Avertissement documentaire et juridique

Cette page analyse les dix fichiers du dossier local pieces/alerte interne/. Elle distingue les faits visibles, les déductions raisonnables et les points que ces seules captures ne permettent pas de trancher. Elle ne remplace ni une expertise informatique des originaux ni une consultation juridique.

Les captures Skype reproduisent une correspondance professionnelle nominative et la capture LinkedIn contient des données personnelles. Leur mise en ligne doit être appréciée au regard de la nécessité documentaire, de la minimisation des données et des droits des personnes concernées.

État de la procédure prud'homale. Par arrêt du 10 mars 2022, la cour d'appel d'Aix-en-Provence a rejeté la qualification de harcèlement moral, écarté la protection invoquée au titre de l'article L.1132-3-3 et jugé le licenciement fondé sur une cause réelle et sérieuse. Je conteste ce raisonnement et la manière dont le dossier a été présenté. Les contrôles CNIL de 2019, dont la conclusion a été publiée en 2025, corroborent ultérieurement le problème de qualification pour le traitement alors examiné ; ils ne constituent pas un audit du code de 2016 et ne réforment ni n'annulent par eux-mêmes cet arrêt.

Rappel applicable à toute mention de l'issue prud'homale dans cette page. J'impute aussi ce résultat à des actes et omissions précisément documentés que je qualifie de fautes professionnelles manifestes, graves et inexcusables commises par Me Camille Poinat. Le grief central est que des fichiers ont été matériellement annexés mais laissés probatoirement inertes faute d'articulation dans les conclusions, tandis qu'aucune demande ciblée de production n'a été adressée à Qwant. Cette qualification, son lien causal et la perte de chance restent à faire juger contradictoirement ; l'arrêt du 10 mars 2022 demeure applicable. Voir l'analyse détaillée du chapitre 31.

Dans la suite, toute référence à ma qualité revendiquée de lanceur d'alerte désigne donc une thèse juridique contestée ; les éléments CNIL postérieurs constituent une corroboration institutionnelle ultérieure et circonscrite au traitement examiné en 2019, et non une validation du code de 2016 ou une remise en cause automatique de l'arrêt.

1. Résumé exécutif📋

Le corpus documente une séquence en deux temps.

Les 25 et 26 août 2016, je publie trois messages sur Twitter :

1. une demande de référence scientifique sur la ré-identification de personnes à partir d'un ensemble d'adresses IP « pseudo-anonymisées » ;
2. une critique ironique de l'idée selon laquelle retirer le dernier octet d'une adresse IP suffirait à supprimer le risque ;
3. une demande de contact publicitaire adressée au compte @MicrosoftAds.

Les deux premiers tweets ne nomment ni Qwant ni Bing. Leur objet visible est néanmoins précis : le risque de ré-identification après troncature ou pseudonymisation d'adresses IP. Le troisième tweet nomme Microsoft Ads, mais la série de captures consacrée aux comptes Microsoft montre que @MicrosoftAds n'était vraisemblablement pas le canal officiel de Microsoft Advertising. Cette conclusion est fortement soutenue par l'apparence du compte, par la trace d'un fichier daté du 8 septembre 2016 et par la comparaison avec les comptes @BingAds puis @MSFTAdvertising. Elle n'est toutefois pas démontrée par un export certifié de Twitter datant d'août 2016.

L'état de l'art disponible à cette date rendait la préoccupation techniquement sérieuse. Une étude conduite par des chercheurs de Microsoft Research et Microsoft Corporation, présentée à NDSS en 2012 et fondée sur les propres journaux Bing et Hotmail de Microsoft, mesurait une précision de 79,33 % pour le suivi d'hôtes à partir du couple User-Agent + préfixe IPv4 /24. Or retirer le dernier octet d'une IPv4 conserve précisément ce préfixe. La documentation des produits commerciaux Bing a ensuite demandé ou fortement recommandé la transmission des mêmes catégories d'attributs — requête, User-Agent, IP cliente et identifiant persistant — afin notamment de localiser, individualiser et corréler l'activité d'un même utilisateur ou terminal. En 2014, l'avis WP216 du G29 avait par ailleurs établi qu'une pseudonymisation ou une généralisation isolée ne produit pas automatiquement des données anonymes. Ces références démontrent la plausibilité connue du risque et la capacité de corrélation du destinataire, non l'attribution d'une identité civile avec une probabilité de 80 %.

L'absence d'identification nominative ne sauve pas la qualification d'anonymat : reconnaître le même hôte et relier ses événements constitue déjà une individualisation et une corrélation. Ajouter à la requête le couple IP /24 + User-Agent réduit logiquement l'ensemble des hôtes compatibles ; sans procédé d'anonymisation robuste démontré, cet ajout va donc dans le sens du fingerprinting, et non de l'anonymisation. Si l'anonymat était présenté comme une caractéristique commerciale essentielle du service, la contradiction peut fonder l'examen d'une pratique commerciale trompeuse. Elle ne suffit pas, à elle seule, à établir l'escroquerie pénale, qui exige notamment la preuve de manœuvres ou d'une tromperie intentionnelle ayant déterminé un acte préjudiciable.

Le dépôt Git de l'API Qwant apporte désormais la preuve directe manquante aux seules captures. Dès le 17 juin 2016, www/application/models/search/search_ads.php construit un appel vers Bing Ads contenant la requête dans q, recopie le User-Agent de l'utilisateur et transmet X-Search-ClientIP après une fonction qui remplace uniquement le dernier octet IPv4 par 0. Le Referer est ajouté le 21 juin. Le fichier figure dans 127 tags datés du 17 juin au 22 décembre 2016, dont v1.32.0 trois jours avant l'échange Skype. Cette continuité prouve le caractère versionné et publié du chemin de code ; les éléments de déploiement restent nécessaires pour quantifier son exécution réelle en production.

Le 19 décembre, dans un échange Skype attribué par le dossier à l'année 2016, la discussion devient incontestablement interne et professionnelle. Je demande si les conditions générales expliquent l'envoi à Bing d'informations dites « pseudo-anonymisées ». Je formule la distinction suivante :

« au sens de la cnil, les infos pseudo anonymisés ne sont pas des infos anonymisés il me semble »

Je précise ensuite :

« ce n'est pas ce que j'ai vu partir en prod »

et :

« mon pb éthique était sur le mensonge de l'usage de bing d'une part […] puis sur l'envoi de ppi pseudo anonymisés à bing sur chaque requête web »

L'interlocutrice répond d'abord que Qwant « n'envoie rien à Bing », puis indique plus loin que « la requête + la provenance de la requête » sont envoyées. Cette évolution constitue le nœud documentaire de l'échange. Elle établit l'existence d'une discussion interne sur le flux vers Bing, l'information donnée aux utilisateurs et les différences entre anonymisation, pseudonymisation et absence de profilage. Elle ne permet pas, à elle seule, de reconstituer tous les champs effectivement transmis ni d'arbitrer définitivement le désaccord technique.

La capture LinkedIn identifie l'interlocutrice comme Legal Officer chez Qwant. La description de ses missions mentionne expressément la conformité auprès de la CNIL, et son expérience antérieure comprend un stage au département conformité de la CNIL. La pièce rend donc cohérent le choix de cet interlocuteur pour un signalement relatif aux données personnelles. Elle ne prouve cependant pas qu'elle était formellement DPO, CIL, supérieure hiérarchique ou référente d'alerte désignée.

Le résultat le plus solide est donc le suivant :

Le corpus documente une préoccupation publique sur la ré-identification en août 2016, puis une notification interne, précise et fondée sur une observation revendiquée de la production, adressée le 19 décembre à une juriste de Qwant dont les missions affichées comprenaient la conformité CNIL. L'historique Git corrobore matériellement le cœur technique de l'alerte : le code versionné associait, dans l'appel Bing Ads, la requête, le User-Agent, le Referer et une IPv4 tronquée au niveau /24.

2. Périmètre, méthode et conventions de transcription📋

2.1. Périmètre📋

Le dossier contient dix images PNG :

• trois captures de tweets ;
• quatre captures relatives aux comptes @MicrosoftAds, @BingAds et @MSFTAdvertising ;
• deux captures d'une conversation Skype ;
• une capture de profil LinkedIn.

Aucun PDF, export Twitter, export Skype, fichier source de messagerie, en-tête technique ou constat d'huissier n'est présent dans ce sous-dossier.

2.2. Méthode📋

Chaque pièce a été :

• ouverte à sa résolution d'origine ;
• transcrite directement depuis l'image ;
• rapprochée des autres captures du même dossier ;
• contrôlée par son nom, ses dimensions, sa taille et son empreinte SHA-256 ;
• analysée sans attribuer aux captures ce qu'elles ne montrent pas.

Les fautes, abréviations et variations de casse sont conservées dans les citations. L'acronyme ppi, visible dans les captures Skype, n'est pas développé parce que le corpus n'en fournit pas la définition. Les emojis sont restitués lorsqu'ils participent au ton de l'échange.

2.3. Limites de datation et d'attribution📋

Les dates visibles ne sont pas homogènes :

• P02 affiche explicitement le 25 août 2016 à 05:46 ;
• P03 affiche seulement « 12 h » ; sa date du 25 août 2016 provient du nom de fichier et du classement du corpus ;
• P04 affiche « 4 h » et une URL contenant l'identifiant de statut 769106417378816001. Le décodage de cet identifiant Twitter situe sa création le 26 août 2016 à 09:37:13 UTC, soit 11:37 en France métropolitaine à cette date ;
• P11a et P11b affichent le 19/12, sans année visible. L'année 2016 résulte du classement du dossier et de la chronologie générale, non d'un horodatage complet montré par les images.

Les bulles Skype bleu-gris, alignées à droite, sont attribuées au titulaire de la session capturée ; les bulles gris foncé, alignées à gauche, à « Victoire », nom affiché dans l'en-tête. Cette attribution est cohérente avec le contenu à la première personne, mais les images ne constituent pas un export signé de la conversation.

3. Inventaire intégral des fichiers📋

3.1. Empreintes SHA-256📋

Ces empreintes identifient exactement les fichiers analysés dans l'état actuel du dépôt :

Ces empreintes garantissent l'identification des copies locales. Elles ne prouvent ni la date de création des captures ni l'authenticité de l'événement représenté.

4. Chapitre I - T1 : la question de la ré-identification📋

Pièce P02 - Tweet affiché au 25 août 2016 à 05:46.

4.1. Transcription📋

« Qq1 saurait retrouver ce papier de recherche déclarant qu'avec un nuage d'IPs pseudo-anonymisés, on pouvait identifier les personnes ? ~ ? »

4.2. Ce que la pièce établit📋

Le message :

• est formulé comme une question ;
• cherche une source scientifique ;
• vise explicitement la possibilité d'identifier des personnes ;
• emploie l'expression « IPs pseudo-anonymisés » ;
• ne cite ni Qwant, ni Bing, ni Microsoft, ni un produit déterminé.

La ponctuation interrogative et la demande de référence comptent : la capture montre une interrogation technique, pas l'affirmation catégorique qu'une entreprise déterminée aurait déjà ré-identifié des utilisateurs.

4.3. Portée analytique📋

T1 fixe le problème de fond : une modification partielle d'un identifiant réseau ne suffit pas nécessairement à rendre impossible toute identification, surtout lorsqu'un destinataire dispose d'autres informations permettant une corrélation.

Le tweet ne décrit toutefois :

• ni la taille exacte du « nuage » d'adresses IP ;
• ni les données associées ;
• ni la méthode de ré-identification ;
• ni le flux technique de Qwant ;
• ni l'identité de l'acteur susceptible de ré-identifier.

Sa portée probatoire est donc celle d'un signal d'alerte technique public et général. Le rattachement de cette question à Qwant nécessite d'autres pièces.

5. Chapitre II - T2 : la troncature du dernier octet📋

Pièce P03 - Tweet affiché comme publié « il y a 12 h » ; le 25 août 2016 provient du nom et du classement du fichier.

5.1. Transcription📋

« ~ "oh non t'inquiète, on enlève le dernier octet, ça ne craint rien" »

La carte jointe affiche :

"Anonymized" data really isn't—and here's why not

et le domaine arstechnica.com.

5.2. Ce que la pièce établit📋

T2 complète T1 en identifiant la transformation technique critiquée : le retrait du dernier octet d'une adresse IP. Le ton est ironique. Les guillemets mettent en scène un discours rassurant selon lequel cette opération supprimerait le risque.

Comme T1, T2 ne nomme pas Qwant. La carte Ars Technica porte plus largement sur les limites de données présentées comme anonymisées. La capture ne montre pas l'URL complète de l'article ni son texte intégral.

5.3. Portée analytique📋

Le rapprochement T1/T2 forme une unité cohérente :

Ces tweets documentent que la distinction entre anonymisation réelle et réduction partielle de précision était au centre de ma préoccupation dès août 2016. Ils ne prouvent pas, isolément, qu'un traitement déterminé de Qwant était illicite.

6. Chapitre III - T3 et l'identité du compte Microsoft contacté📋

6.1. Le tweet T3📋

Pièce P04 - Tweet adressé à @MicrosoftAds. L'identifiant de statut visible correspond au 26 août 2016 à 09:37 UTC.

« @MicrosoftAds Hi, I'd like my website to publish some ads to generate some revenue. May I have a contact with you ? Thanks. »

Traduction :

« Bonjour @MicrosoftAds, j'aimerais que mon site publie des publicités pour générer des revenus. Pourrais-je obtenir un contact chez vous ? Merci. »

6.2. Correction de chronologie📋

P04 affiche l'URL :

https://twitter.com/lolal_j/status/769106417378816001

Un identifiant Twitter de cette génération contient son horodatage. Celui-ci correspond au 26 août 2016 à 09:37:13 UTC, et non au 25 août. La capture montre en outre « 4 h », ce qui est compatible avec une capture effectuée quelques heures plus tard.

La formulation rigoureuse est donc :

• T1 est explicitement daté du 25 août 2016 ;
• T2 est classé au 25 août, mais sa capture n'affiche qu'un âge relatif ;
• T3 date vraisemblablement du 26 août 2016 d'après l'identifiant visible.

6.3. Le profil @MicrosoftAds📋

Pièce P05a - Profil @MicrosoftAds, nommé « MicroSoft Ads Center ».

La capture montre :

• le nom « MicroSoft Ads Center » ;
• le compte @MicrosoftAds ;
• cinq publications ;
• 152 abonnés et 135 abonnements ;
• un ancien visuel Windows XP ;
• l'absence de badge de vérification ;
• une biographie en anglais maladroit proposant un programme publicitaire via un lien raccourci ;
• une date d'inscription en août 2009.

Ces indices sont incompatibles avec l'apparence attendue d'un grand compte de marque officiel. Ils soutiennent fortement la conclusion selon laquelle T3 a interpellé un compte non officiel ou d'imitation.

La capture ne montre cependant pas :

• la date à laquelle ce profil a été consulté ;
• l'état exact du profil au 26 août 2016 ;
• une déclaration de Microsoft désavouant ce compte ;
• l'historique complet des changements de nom et de biographie.

Le nom de fichier P05a_Faux_compte_MicrosoftAds.png est une qualification donnée par le dossier, non une preuve autonome.

6.4. La trace Google Drive📋

Pièce P05b - Liste de fichiers affichant deux dates relatives aux captures de @MicrosoftAds.

La liste montre notamment :

• microsoftads.PNG, daté du 8 janvier 2018 ;
• compte microsoftads is a fake.PNG, daté du 8 septembre 2016.

Cette seconde ligne est importante : elle indique qu'un fichier ainsi nommé était déjà répertorié moins de deux semaines après T3. Elle renforce la contemporanéité de la contestation du caractère officiel de @MicrosoftAds.

Mais P05b reste une capture d'interface :

• elle ne fournit pas le contenu en pleine résolution du fichier du 8 septembre 2016 ;
• elle ne précise pas si la date affichée est une création, une modification ou un ajout dans Drive ;
• elle ne contient pas l'empreinte du fichier d'origine ;
• son libellé « is a fake » est celui donné par l'auteur du fichier.

P05b est donc un élément de provenance secondaire, pas un constat indépendant de Twitter.

6.5. Les comptes officiels @BingAds et @MSFTAdvertising📋

Pièce P06 - Le compte @BingAds affiche « Now @MSFTAdvertising ».

P06 montre un petit compte @BingAds, inscrit en avril 2019, dont le nom et la biographie renvoient vers @MSFTAdvertising. Cette capture est cohérente avec une réservation de l'ancien identifiant après changement de marque.

Pièce P07 - Profil vérifié @MSFTAdvertising, inscrit en juillet 2008.

P07 montre :

• le nom vérifié « Microsoft Advertising » ;
• le compte @MSFTAdvertising ;
• 72 700 abonnés ;
• 38 300 publications ;
• le site about.ads.microsoft.com ;
• une inscription en juillet 2008.

Le rapprochement de P06 et P07 établit le canal officiel au moment de ces captures et la continuité de marque entre Bing Ads et Microsoft Advertising. Il ne reconstitue pas à lui seul tous les identifiants utilisés par Microsoft le 26 août 2016.

6.6. Conclusion sur T3📋

Les quatre pièces conduisent à une conclusion graduée :

• directement établi : T3 a été adressé à @MicrosoftAds ;
• fortement soutenu : ce compte n'était pas le compte officiel de Microsoft Advertising ;
• non établi par le sous-dossier seul : l'état exact de ce compte au jour de T3 et la connaissance que j'avais alors de son caractère non officiel ;
• non établi : l'existence d'une démarche commerciale effective, d'un contrat, d'un échange privé ou d'un revenu personnel.

T3 est un message public demandant un contact. Il ne montre aucune suite.

7. Chapitre IV - Première capture Skype : CGU, FAQ et qualification des données📋

Pièce P11a - Conversation affichée au 19/12 ; l'année 2016 provient du classement du corpus.

7.1. Transcription intégrale visible📋

Moi :

« ils parlent de l'envoi d'infos pseuso-anonymisés à bing aussi dans les cgu ? »

Victoire :

« non non t'inquiète ça aussi on l'explique bien 😁 »

Moi :

« bah j'ai pas vu, mais bon, j'regarde pas tous les jours »

Victoire :

« je pense que le but c'est vraiment de faire qqch de propre, en tout cas le recrutement de g.champeau est pour pousser dans ce sens là c'est sûr »

« j'espère que ça marchera 😁 »

Moi :

« espérons, mais bon, j'ai des doutes »

« je vois rien sur l'envoi de ppi pseudo anonymisés à bing 😬 et en mm temps il me semble que les cgi disent que rien n'est envoyé; au sens de la cnil, les infos pseudo anonymisés ne sont pas des infos anonymisés il me semble »

« cgu »

« mais effectivement, l'ajout de bing dans les faq semble avoir été fait après ma mise en arrêt maladie »

« ou plutôt lite n'est pas mis à jour https://lite.qwant.com/faq↗ (ouvre dans une nouvelle fenêtre) »

7.2. Les quatre questions soulevées📋

Cette première capture contient quatre sujets distincts.

A. L'information contractuelle📋

La question initiale porte sur ce que les CGU disent de l'envoi à Bing. Il ne s'agit pas seulement de savoir si un flux existe, mais si les utilisateurs en sont informés.

B. La nature des données📋

L'expression « pseudo anonymisés » place le débat sur le statut des données. Je soutiens que des informations pseudonymisées ne sont pas, pour cette seule raison, anonymes.

C. La chronologie de la FAQ📋

J'indique que l'ajout de Bing dans la FAQ paraît postérieur à mon arrêt maladie. La phrase est prudente : « semble avoir été fait ». Puis je nuance encore en envisageant que seule la FAQ de Qwant Lite ne soit pas à jour.

D. L'existence de plusieurs supports divergents📋

La correction « ou plutôt lite n'est pas mis à jour » montre qu'une différence entre versions de FAQ est envisagée. La capture ne permet pas de dater les versions ni d'établir laquelle était juridiquement opposable.

7.3. Portée analytique📋

P11a est une pièce forte pour établir :

• une alerte interne sur la transparence du flux vers Bing ;
• l'emploi explicite du vocabulaire CNIL ;
• une distinction entre pseudonymisation et anonymisation ;
• une vérification active des CGU et FAQ ;
• la prudence de l'auteur, qui corrige sa propre hypothèse.

Elle ne prouve pas :

• le contenu exact de toutes les CGU et FAQ à chaque date ;
• la date précise de leur mise à jour ;
• le contenu technique du flux ;
• que l'interlocutrice disposait d'une connaissance directe du code ;
• qu'une autorité avait déjà qualifié le traitement.

8. Chapitre V - Seconde capture Skype : ce qui partait en production📋

Pièce P11b - Suite de la conversation affichée au 19/12.

8.1. Transcription intégrale visible📋

Victoire :

« ben en fait on envoie rien à Bing, c'est eux qui récupèrent l'ip une fois que l'user sort du site qwant.com »

Moi :

« ce n'est pas ce que j'ai vu partir en prod 😁 »

Victoire :

« comme lorsqu'on clique sur n'importe quel lien dans le moteur en fait »

« t'as vu quoi ? »

« enfin quoiqu'il en soit ils ont pas besoin qu'on leur envoie quoi que ce soit pour faire leur tracking habituel »

Moi :

« bah l'envoi d'infos pseudo anonymisés; le code php derrière api.qwant.com a (avait?) accès à l'ip complète de l'utilisateur »

Victoire :

« la différenciation c'est qu'avec Qwant on conserve aucun historique de recherches, donc pas de profil établi à partir de l'historique des requêtes sur qwant »

Moi :

« je sais bien, et j'ai confiance en ça »

Victoire :

« "avait" je pense »

« et Qwant ne fait aucun profiling non plus »

Moi :

« je sais bien, mon pb éthique était sur le mensonge de l'usage de bing d'une part, à l'époque en tout cas, puis sur l'envoi de ppi pseudo anonymisés à bing sur chaque requête web »

« pour avoir un retour de bing + ads »

Victoire :

« ben ce qui est envoyé, c'est que la requête + la provenance de la requête cad une mention comme quoi elle vient de qwant »

« pour nos stats »

8.2. Le désaccord technique📋

Deux représentations du flux apparaissent.

8.3. Une contradiction apparente à ne pas simplifier📋

Le début dit :

« on envoie rien à Bing »

La fin dit :

« ce qui est envoyé, c'est que la requête + la provenance de la requête »

Pris littéralement, ces énoncés sont incompatibles. Dans le contexte, « rien » peut toutefois signifier « aucune adresse IP ou donnée identifiante directement envoyée par Qwant », tandis que la seconde phrase admet l'envoi de la requête et de sa provenance. Le corpus ne permet pas de savoir si cette restriction implicite était celle de l'interlocutrice.

La conclusion rigoureuse n'est donc pas « Victoire reconnaît tout le flux allégué », mais :

L'interlocutrice passe d'une négation générale à la reconnaissance d'au moins deux éléments transmis - la requête et sa provenance - tout en contestant ou en déplaçant la question de l'adresse IP et du profilage.

8.4. La valeur de « ce que j'ai vu partir en prod »📋

Cette phrase est importante parce qu'elle revendique une connaissance professionnelle directe. Elle est renforcée par la mention du code PHP derrière api.qwant.com et par l'opposition entre présent et passé : « a (avait?) accès ».

Elle demeure néanmoins une déclaration dans une conversation. Pour transformer cette affirmation en démonstration technique complète, il faudrait notamment :

• le code correspondant à la version de production ;
• les journaux réseau ou captures de trafic ;
• la liste exacte des paramètres transmis ;
• la date de déploiement ;
• l'identité des destinataires et sous-traitants ;
• les politiques de confidentialité applicables à cette date.

8.5. Ce que l'échange révèle sur la bonne foi📋

Plusieurs formulations vont à l'encontre d'une présentation purement accusatoire :

• « il me semble » ;
• « semble avoir été fait » ;
• « ou plutôt » ;
• « a (avait?) » ;
• « à l'époque en tout cas » ;
• « je sais bien, et j'ai confiance en ça ».

Je distingue le point accepté - l'absence alléguée d'historique et de profilage par Qwant - du point contesté - la transmission à Bing et l'information donnée. Cette capacité à reconnaître un élément favorable à l'entreprise est un indice de discussion de bonne foi. Elle ne suffit pas, à elle seule, à emporter une qualification juridique.

9. Chapitre VI - La destinataire de l'alerte📋

Pièce P11c - Profil LinkedIn affichant les fonctions de la destinataire de la conversation.

9.1. Informations visibles📋

La capture présente Victoire Yau comme :

• Legal Officer - QWANT ;
• en fonction depuis avril 2015 au moment de la capture ;
• située dans la région de Nice ;
• ancienne Legal Intern - Compliance Department à la CNIL, de février à juillet 2014.

La description de son poste chez Qwant mentionne notamment :

• le contact juridique interne avec les cabinets et partenaires ;
• le conseil à la direction ;
• l'analyse des risques juridiques liés aux partenariats ;
• la conformité auprès de l'autorité française de protection des données, la CNIL ;
• la rédaction de documents et contrats ;
• le conseil et le support contentieux ;
• la veille juridique.

LinkedIn affiche également que nous travaillions tous deux chez Qwant et qu'elle avait commencé un mois après moi.

9.2. Ce que la pièce permet de conclure📋

La destinataire disposait, selon son propre profil professionnel :

• d'une fonction juridique interne ;
• d'une mission explicitement liée à la conformité CNIL ;
• d'une expérience antérieure au sein du département conformité de la CNIL ;
• d'une mission d'analyse des risques dans les partenariats, pertinente pour un flux vers Microsoft/Bing.

Elle était donc une interlocutrice professionnellement cohérente pour recevoir une alerte portant sur les données personnelles, les mentions contractuelles et un partenaire.

9.3. Ce que la pièce ne permet pas de conclure📋

La capture ne comporte pas les titres :

• « déléguée à la protection des données » ou DPO ;
• « correspondante Informatique et Libertés » ou CIL ;
• « référente alerte » ;
• « supérieure hiérarchique ».

Elle ne montre pas non plus une désignation formelle par Qwant pour recevoir les signalements au titre de la loi Sapin II. Employer ces qualités comme des faits établis dépasserait la pièce.

La formulation fidèle est :

« Legal Officer de Qwant dont les missions affichées comprenaient la conformité CNIL et l'analyse des risques juridiques liés aux partenariats. »

10. Chapitre VII - Reconstitution chronologique📋

Cette chronologie empêche trois raccourcis :

1. T3 ne doit pas être daté automatiquement du 25 août ;
2. les états récents des profils Twitter ne doivent pas être projetés sans réserve sur août 2016 ;
3. le 19 décembre est visible dans Skype, mais l'année 2016 reste à corroborer par un export ou une pièce externe.

11. Chapitre VIII - Analyse technique📋

11.1. Anonymisation et pseudonymisation📋

L'intuition exprimée dans l'échange est conforme à une distinction déjà formulée avant 2016 par les autorités européennes de protection des données : remplacer ou supprimer un attribut ne rend pas automatiquement un ensemble anonyme si l'individualisation, la corrélation ou l'inférence restent possibles.

La pseudonymisation réduit le lien direct avec une identité ; l'anonymisation suppose que l'identification ne soit plus raisonnablement possible. Une adresse IP tronquée peut réduire la précision sans perdre nécessairement son caractère de quasi-identifiant, surtout si elle est associée à une requête, un navigateur, un horaire ou d'autres informations.

Cette règle générale ne suffit pas à qualifier le flux de Qwant. Il faut connaître l'ensemble transmis, le destinataire, ses moyens de corrélation, les finalités et les garanties.

11.2. Les flux possibles évoqués dans Skype📋

La conversation mélange ou compare au moins trois opérations :

1. la requête envoyée par Qwant pour obtenir des résultats Web ;
2. les informations utilisées pour obtenir ou mesurer des publicités ;
3. l'IP reçue par un site tiers lorsque l'utilisateur clique sur un résultat et quitte Qwant.

Ces opérations peuvent coexister. Dire qu'un site tiers voit l'IP lors d'un clic sortant ne répond donc pas nécessairement à la question de ce qui est transmis en amont, lors de chaque requête.

Le dialogue montre précisément ce glissement :

Question : que transmet Qwant à Bing pendant la requête ?
Réponse initiale : Bing voit l'IP lorsque l'utilisateur quitte Qwant.
Réponse finale : la requête et sa provenance sont envoyées.
Point restant contesté : quelles autres informations partent avec la requête ?

11.3. Absence de profilage et absence de transmission ne sont pas synonymes📋

L'interlocutrice insiste sur l'absence d'historique et de profilage par Qwant. Je ne conteste pas ce point dans l'échange. Mais trois propositions différentes doivent être séparées :

• Qwant ne conserve pas d'historique ;
• Qwant ne crée pas de profil ;
• Qwant ne transmet aucune donnée à Bing.

La vérité éventuelle des deux premières n'entraîne pas automatiquement celle de la troisième. Inversement, l'existence d'une transmission ne prouve pas à elle seule un profilage, une ré-identification effective ou une illégalité.

11.4. Le cœur technique effectivement documenté📋

Le corpus établit que, le 19 décembre :

• l'existence d'un flux vers Bing faisait l'objet d'une discussion interne ;
• l'envoi de la requête et de sa provenance était admis par l'interlocutrice ;
• j'affirmais que d'autres informations pseudonymisées partaient en production ;
• j'affirmais que le code de l'API avait eu accès à l'IP complète ;
• les participants distinguaient le flux de requête, le clic sortant et le profilage.

Les seules captures ne permettent pas d'établir :

• la valeur exacte de l'IP transmise ;
• la présence d'un User-Agent, d'un identifiant publicitaire ou d'un cookie ;
• le pays de traitement ;
• la durée de conservation ;
• la base légale ;
• l'existence d'une ré-identification effective.

12. Chapitre IX - Preuve par le code📋

Le dépôt Git local communiqué pour cette analyse est situé hors du présent dossier, dans :

C:\Users\serard\Documents\AttaQwant\source\API-API-TAG-PACKAGER

Conformément à la consigne de préservation, aucune opération susceptible de modifier ce dépôt ou son espace de travail n'a été exécutée. L'examen repose exclusivement sur des commandes git log appliquées à l'historique, aux patches et aux décorations de tags. Aucun checkout, changement de branche, restauration, indexation, nettoyage ou écriture n'a été effectué.

Le fichier identifié dans l'historique est :

www/application/models/search/search_ads.php

12.1. Ce que le commit d'origine établit📋

Le fichier est ajouté par le commit b4ba79ddfe7a477bc0c917e63fe0c4fd4bc4f3f0, daté du 17 juin 2016 à 10:43:34 +02:00, avec le message #QWANT-210 search ads.

Le patch d'ajout montre simultanément quatre opérations.

Premièrement, le code construit une URL vers l'API publicitaire Bing et y place directement la recherche de l'utilisateur dans le paramètre q :

$apiCall = 'https://www.bing.com/api/v5/ads/search?...'
    . '&q=' . urlencode($keyword)

Deuxièmement, il recopie le User-Agent reçu par l'API Qwant dans l'appel sortant :

$extraOptions[CURLOPT_USERAGENT] = $this->input->user_agent();

Troisièmement, il ajoute un en-tête contenant l'adresse IP transformée :

$extraOptions[CURLOPT_HTTPHEADER] = [
    'X-Search-ClientIP: ' . $this->anonymizeIp($this->input->ip_address())
];

Quatrièmement, la fonction appelée « anonymisation » est entièrement visible :

private function anonymizeIp($ip)
{
    $lastPoint = strrpos($ip, '.');
    return ($lastPoint !== false)
        ? substr($ip, 0, $lastPoint) . '.0'
        : $ip;
}

Pour une adresse IPv4, cette fonction remplace uniquement la partie située après le dernier point par 0. Elle transforme donc normalement A.B.C.D en A.B.C.0 et conserve le préfixe /24. Il s'agit exactement de la généralisation étudiée dans l'article NDSS de Microsoft Research, dont le couple User-Agent + IP /24 atteignait 79,33 % de précision pour distinguer des hôtes dans les journaux Bing.

Le second embranchement est également important : si la chaîne ne contient aucun point, la fonction renvoie l'entrée sans aucune modification. Appliquée à une adresse IPv6 écrite sous sa forme ordinaire, elle ne réalise donc aucune troncature. Le code ne démontre pas à lui seul que le service acceptait effectivement des IPv6 à cette date, mais la fonction, prise littéralement, ne les anonymise pas.

12.2. Le Referer, l'IP et le User-Agent sont explicitement des en-têtes requis par Bing Ads📋

Le commit dcb7e92d2f226e9bd099181edbe196f9b7796ff4, daté du 21 juin 2016 à 18:35:24 +02:00 et intitulé add referer to bing Ads call, ajoute le Referer de la requête d'origine aux options transmises :

$referer = !empty($_SERVER['HTTP_REFERER'])
    ? $_SERVER['HTTP_REFERER']
    : 'http://www.qwant.com/';

$extraOptions[CURLOPT_HTTPHEADER] = [
    'X-Search-ClientIP: ' . $ipAddress,
    'Referer: ' . $referer
];

Les versions postérieures déplacent le Referer vers l'option cURL dédiée sans en supprimer la transmission :

$extraOptions[CURLOPT_USERAGENT] = $userAgent;
$extraOptions[CURLOPT_HTTPHEADER] = [
    'X-Search-ClientIP: ' . $ipAddress
];
$extraOptions[CURLOPT_REFERER] = $referer;

À la fin du mois d'août, le code porte lui-même ce commentaire :

// Bing Ads required headers:
// Referer, IP address, User agent

Cette formulation interne est particulièrement probante. Elle ne décrit pas une possibilité théorique : elle nomme comme exigences de l'appel Bing Ads les trois informations effectivement préparées juste après par le code.

12.3. La requête, l'empreinte d'hôte et la provenance partent dans le même appel📋

La lecture combinée du constructeur d'URL et des options cURL permet de reconstituer le flux sortant prévu par search_ads.php :

Le commit 490891b0f870faaf87ec02ca3e719176ee0ff51f, daté du 23 août 2016, porte en outre le message Extend ads too other locales and to all web queries #QWANT-335. Son intitulé documente l'extension du mécanisme publicitaire à toutes les requêtes web, sous réserve de la logique exacte, des configurations et des taux d'activation présents dans chaque version.

Le 29 novembre, le commit 43f796e4ea63beaf8c8cae8418dc63818eb081a4 distingue explicitement :

$ipAddress = $this->input->ip_address();
$ipAddressAnonymized = $this->anonymizeIp($ipAddress);
$userAgent = $this->input->user_agent();

$config['client_ip'] = $ipAddress;
$extraOptions[CURLOPT_USERAGENT] = $userAgent;
$extraOptions[CURLOPT_HTTPHEADER] = [
    'X-Search-ClientIP: ' . $ipAddressAnonymized
];

La même modification emploie l'IP complète pour calculer un hash salé servant à répartir les utilisateurs dans un test A/B :

$userHash = hash('sha256', $config['client_ip'] . SALT_CLIENT_HASH);

Il faut distinguer les deux faits. Ce patch montre que l'application disposait de l'IP complète et l'utilisait pour produire un identifiant de répartition stable ; il montre parallèlement que l'en-tête Bing recevait la version IPv4 tronquée. Il ne montre pas, dans ce passage, que l'IP complète était envoyée telle quelle à Bing.

12.4. Conséquence directe pour l'alerte du 19 décembre📋

Le code tranche plusieurs points que les seules captures Skype laissaient encore ouverts :

• le code de l'API avait bien accès à l'adresse IP complète de l'utilisateur ;
• un appel sortant était bien adressé à l'API Bing Ads ;
• la requête de recherche était placée dans cet appel ;
• le User-Agent de l'utilisateur était transmis ;
• un X-Search-ClientIP était transmis avec l'IPv4 ramenée à son préfixe /24 ;
• le Referer était également transmis ;
• la fonction qualifiée d'« anonymisation » n'effectuait qu'une troncature du dernier octet IPv4 et ne transformait pas une adresse sans point.

Ces éléments correspondent matériellement au problème formulé dans l'alerte. Le code associe dans le même appel la requête, le User-Agent, le préfixe IP et la provenance. Or le destinataire est précisément Microsoft/Bing, qui avait déjà publié sur ses propres journaux le pouvoir d'individualisation du couple User-Agent + /24.

La conclusion technique ne dépend donc plus seulement d'une possibilité abstraite :

Le code de search_ads.php constitue une preuve directe que Qwant avait programmé la transmission à Bing Ads de la requête et d'attributs provenant de l'utilisateur, dont le User-Agent, le Referer et l'adresse IPv4 tronquée au niveau /24. Cette combinaison allait logiquement dans le sens de l'individualisation et de la corrélation d'un hôte. L'appeler « anonymisation » dans le nom de la fonction ne pouvait modifier la nature ni le pouvoir distinctif des données effectivement produites.

12.5. Portée et limites probatoires du dépôt📋

L'historique Git établit le contenu versionné, ses dates de commit, sa diffusion dans les branches historiques et sa présence dans les tags recensés. Il renforce fortement l'affirmation « ce que j'ai vu partir en production » en montrant un chemin de code cohérent et contemporain de l'alerte.

Il ne prouve cependant pas, sans éléments de déploiement complémentaires :

• qu'un tag déterminé a été déployé sur tous les serveurs à la date de son commit ;
• la valeur des variables de configuration et les pourcentages d'activation en production ;
• le nombre exact de requêtes réellement envoyées ;
• les journaux effectivement conservés par Qwant ou Microsoft ;
• les traitements réalisés ensuite par Microsoft ;
• l'intégrité forensique ou l'origine distante du dépôt local communiqué.

Pour une production judiciaire, il serait utile d'ajouter un constat de l'origine du dépôt, les empreintes des objets Git, les références distantes historiques, les éléments de CI/CD et les journaux de déploiement. Ces réserves n'annulent pas ce que les patches montrent directement ; elles délimitent la différence entre code versionné, code déployé et traitement effectivement exécuté.

12.6. Tous les tags contenant search_ads.php📋

Le recensement a été effectué exclusivement avec git log. Les tags ont d'abord été extraits des décorations de commits. Pour chacun, le dernier changement du chemin sur son historique de premier parent a ensuite été obtenu par git log -m --first-parent --full-history -1 --name-status. Les 127 tags ci-dessous présentent tous un dernier état A ou M, jamais D.

La date indiquée est la date de commit du commit visé par le tag, telle que retournée par %cI. Elle ne doit pas être confondue avec une éventuelle date de création ou de signature d'un tag annoté, que la méthode imposée par git log ne permet pas d'établir uniformément.

La continuité est donc documentée depuis v1.18.4, le jour même de l'introduction du fichier sur la lignée publiée, jusqu'à v1.32.1, trois jours après la conversation Skype du 19 décembre. La présence dans un tag ne prouve pas isolément son déploiement, mais elle exclut l'hypothèse d'un simple fichier de travail fugitif limité à un commit sans diffusion dans les versions étiquetées.

13. Chapitre X - État de l'art de la ré-identification : connaissances disponibles avant et après l'alerte📋

L'analyse de l'alerte suppose de distinguer deux questions :

1. que savait-on raisonnablement, en 2016, des risques de ré-identification à partir d'une adresse IP tronquée et d'autres attributs ?
2. dans quelle mesure les contrôles CNIL de 2019, publiés en 2025, corroborent-ils cette qualification à partir de critères déjà disponibles en 2016, sans auditer pour autant le code historique ?

Cinq ensembles documentaires apportent une réponse convergente : l'étude conduite par Microsoft et présentée à NDSS en 2012, l'avis européen 05/2014 référencé WP216, le code Qwant de 2016, les pièces biffées OCR issues des contrôles CNIL de 2019, puis la notice publique de la CNIL en 2025.

13.1. NDSS 2012 : Microsoft Research analyse ses propres journaux Bing📋

L'article de Ting-Fang Yen, Yinglian Xie, Fang Yu, Roger Peng Yu et Martín Abadi, intitulé Host Fingerprinting and Tracking on the Web: Privacy and Security Implications↗ (ouvre dans une nouvelle fenêtre), a été présenté le 8 février 2012 au symposium NDSS. Les affiliations publiées comprennent Microsoft Research et Microsoft Corporation.

Il ne s'agit pas d'une analyse extérieure menée sur des données reconstituées. Trois auteurs sont affiliés à Microsoft Research Silicon Valley, un autre à Microsoft Corporation, et la première auteure a effectué ce travail pendant un stage chez Microsoft Research. L'étude exploite directement trois jeux internes de Microsoft, dont un mois de requêtes adressées au moteur Bing en août 2010 et un mois de connexions Hotmail. Le jeu Bing étudié contenait :

• la chaîne User-Agent, hachée dans le jeu de recherche ;
• l'adresse IP ;
• l'horodatage de la requête ;
• un identifiant de cookie pseudonymisé et persistant ;
• la date de création de ce cookie.

Les auteurs ne se contentent donc pas d'une hypothèse abstraite sur la ré-identification. Ils mesurent le pouvoir de suivi d'attributs couramment présents dans des journaux de services web. Dans leur métrique, la « précision » désigne la proportion des empreintes étudiées correspondant à un seul identifiant matériel dans le jeu de validation ; elle ne mesure pas l'attribution d'un nom civil. Leurs résultats principaux sont les suivants :

Pour une adresse IPv4, retirer le dernier octet revient normalement à ne conserver que son préfixe /24. L'expérience est donc particulièrement proche de la transformation évoquée dans T2. Dans le jeu étudié, le résultat User-Agent + /24 est presque aussi précis que le couple comprenant l'adresse IP complète : 79,33 % contre 80,62 %. Les auteurs en déduisent expressément que les techniques conservant le préfixe IP peuvent maintenir un pouvoir distinctif.

Le même article montre également que des hôtes peuvent continuer à être suivis après suppression de leurs cookies ou utilisation de la navigation privée : 88 % des cookies observés une seule fois ont pu être rattachés à des hôtes revenus ultérieurement. Il établit ainsi, dès 2012, que la disparition d'un identifiant direct ou persistant n'empêche pas nécessairement la corrélation par d'autres signaux.

Ces résultats doivent être employés avec précision :

• l'article mesure principalement l'identification et le suivi d'un hôte ou terminal, validés au moyen d'identifiants matériels, et non l'attribution certaine d'un nom d'état civil ;
• ses pourcentages dépendent de ses jeux de données, de sa période d'observation et de sa méthode ;
• il ne démontre pas que Qwant transmettait effectivement à Bing, en 2016, le même ensemble d'attributs ;
• il ne démontre pas qu'une ré-identification d'utilisateurs de Qwant a effectivement été réalisée.

Il démontre en revanche qu'au sein même de Microsoft, sur les propres journaux du destinataire concerné par l'alerte, la possibilité de distinguer et de suivre des hôtes à partir d'un préfixe IP /24 combiné à un User-Agent était mesurée et publiquement quantifiée quatre ans avant l'alerte.

13.1.1. Les résultats ne dépassent pas 80 % pour le /24, mais ils l'approchent📋

Le chiffre doit être formulé sans l'affaiblir ni lui faire dire autre chose :

• User-Agent + IP complète : 80,62 % de précision ;
• User-Agent + préfixe IP /24 : 79,33 % de précision ;
• cookie : 82,35 % de précision.

La valeur correspondant exactement à la suppression du dernier octet est donc 79,33 %, et non « plus de 80 % ». En revanche, elle n'est inférieure que de 1,29 point au résultat obtenu avec l'IP complète et se situe dans le même ordre de grandeur que le cookie. Cela invalide l'idée selon laquelle la seule troncature rendrait l'information dépourvue de pouvoir individualisant.

La « précision » de l'article désigne la proportion d'empreintes ne correspondant qu'à un seul identifiant matériel dans le jeu de validation. Elle ne signifie pas que Microsoft retrouvait le nom civil d'une personne dans 79,33 % ou 80,62 % des cas. Elle signifie que ces attributs permettaient de distinguer avec une forte précision un même hôte et de relier ses événements.

Cette distinction ne rétablit nullement l'anonymat. Une identification nominative immédiate — nom, prénom ou état civil — n'est pas nécessaire pour individualiser un sujet technique. Lorsqu'une empreinte permet de reconnaître le même hôte au fil des requêtes, elle permet déjà :

• de singulariser son activité ;
• de relier entre elles ses recherches successives ;
• de rattacher à cet hôte les adresses IP ou préfixes IP observés ;
• d'enrichir cette empreinte avec les cookies, comptes, clics publicitaires, horaires, localisations ou autres journaux dont dispose le destinataire ;
• et, si une information directement identifiante devient disponible dans l'un de ces contextes, de rattacher rétrospectivement l'historique corrélé à une personne.

Au sens de l'avis WP216, les deux premiers effets — individualisation et corrélation — suffisent déjà à faire échouer une prétention générale à l'anonymat. Le risque juridique ne commence donc pas seulement au moment où un nom civil apparaît à l'écran.

13.1.2. Des connaissances de Microsoft aux produits Bing commercialisés📋

Microsoft n'a pas seulement publié ce résultat scientifique. Il a commercialisé l'accès à Bing sous forme d'API. L'annonce officielle de la mise à disposition générale des Bing Search APIs v7 sur Azure↗ (ouvre dans une nouvelle fenêtre) renvoie explicitement à des offres, des tarifs et à un service de qualité commerciale.

La documentation Microsoft du Bing Web Search SDK↗ (ouvre dans une nouvelle fenêtre) décrit notamment les attributs suivants :

Microsoft indique expressément que le ClientID persistant peut servir à :

• adapter les résultats à l'historique de recherche associé à cet identifiant ;
• analyser l'activité produite par cet identifiant ;
• améliorer le classement des résultats ;
• maintenir une expérience cohérente entre plusieurs appels ;
• augmenter le taux de clic obtenu par le consommateur de l'API.

Il s'agit précisément de fonctions d'individualisation et de corrélation : plusieurs requêtes sont reconnues comme provenant du même utilisateur ou terminal et peuvent être rattachées à un historique. L'identifiant est qualifié d'unique et doit persister entre les sessions. Ce fonctionnement peut ne pas révéler immédiatement un nom civil ; il n'est pas pour autant anonyme au sens technique et juridique du WP216.

La documentation actuelle de la Conversions API de Microsoft Advertising↗ (ouvre dans une nouvelle fenêtre) rend la finalité de rapprochement encore plus explicite. Elle demande notamment l'horodatage, le User-Agent et l'adresse IP de l'utilisateur afin d'associer un événement à d'autres activités, telles que les clics publicitaires. Elle prévoit également des identifiants visiteurs persistants destinés à agréger les événements d'un même utilisateur dans le temps, à synchroniser son identité technique entre différents contextes, à attribuer les conversions et à constituer des audiences.

Cette documentation Advertising est postérieure aux faits et ne décrit pas nécessairement l'interface privée utilisée entre Qwant et Microsoft en 2016. Elle ne doit donc pas être projetée rétroactivement sur ce flux. Elle confirme toutefois que, dans les produits commerciaux de Microsoft, les catégories IP + User-Agent + horodatage + identifiant ont une utilité explicite de rapprochement et de suivi, et non une nature intrinsèquement anonyme.

Il faut aussi distinguer les produits :

• les Bing Search APIs servent à obtenir des résultats de recherche et documentent les informations relatives à l'utilisateur final ;
• les Microsoft Advertising/Bing Ads APIs couvrent plusieurs interfaces de gestion, de diffusion, de mesure et d'attribution publicitaires ;
• le présent corpus emploie « Bing Ads » pour le flux publicitaire de Qwant, sans identifier à lui seul le nom et la version contractuelle exacts de l'API utilisée en décembre 2016.

Le dossier permet donc d'établir une continuité fonctionnelle, mais pas une causalité intentionnelle non documentée :

Microsoft Research mesure sur les logs Bing
le pouvoir distinctif de User-Agent + IP /24
                    ↓
les API commerciales Bing organisent la transmission
et la persistance d'attributs permettant localisation et corrélation
                    ↓
Qwant transmet ou déclare transmettre à Microsoft
des requêtes et des attributs pseudonymisés
                    ↓
ces données ne peuvent pas être dites anonymes par principe
si Microsoft peut encore individualiser ou relier les événements

Les sources ne prouvent pas que Microsoft a conçu ces API parce que l'étude NDSS avait obtenu 79,33 % ou 80,62 %. Elles prouvent quelque chose de plus sobre et de directement vérifiable : Microsoft connaissait et avait quantifié sur ses propres données le pouvoir distinctif de ces attributs ; ses produits commerciaux demandaient ensuite ces mêmes catégories d'informations et documentaient leur emploi pour la localisation, la continuité, l'historique, la mesure et la corrélation.

13.2. Confrontation avec la qualification publique employée par Qwant📋

Le rapprochement avec la communication de Qwant est direct. Les captures et transcriptions réunies dans le chapitre consacré à sa communication montrent que Qwant a présenté la requête comme « immédiatement anonymisée » et les informations transmises à Microsoft comme « anonymisées », y compris lorsque la liste publiée comprenait les mots-clés recherchés, le User-Agent, les trois premiers octets de l'adresse IP, une zone géographique approximative et un hash salé.

13.2.1. La ré-identification d'un hôte suffit à contredire l'anonymat📋

Cette qualification est incompatible avec une affirmation générale d'anonymat dès lors que le destinataire peut :

• isoler un hôte avec le couple User-Agent + /24 ;
• relier plusieurs événements au même identifiant ou à la même empreinte ;
• rapprocher la requête de ses propres journaux, cookies, comptes ou identifiants publicitaires ;
• déduire une localisation ou enrichir un historique.

La contradiction ne dépend donc pas de la preuve qu'un nom civil aurait effectivement été retrouvé. Le host fingerprinting ne dit pas nécessairement « cet hôte appartient à Mme X » ; il dit d'abord « ces événements proviennent très probablement du même hôte ». Cette reconnaissance persistante rend possible le rattachement des adresses IP successives, des requêtes et des autres signaux à une même entité technique. Au sens du WP216, la persistance d'une capacité raisonnable d'individualisation ou de corrélation suffit à maintenir le caractère personnel ou pseudonyme des données.

Il faut toutefois formuler exactement le rapport entre adresse IP, hôte et personne. Une adresse IP n'est pas une bijection universelle avec une personne : elle peut être dynamique, partagée entre plusieurs personnes ou terminaux, placée derrière une traduction d'adresses (NAT), et une même personne peut employer plusieurs adresses. La formule littérale « une IP = une personne » est donc techniquement inexacte.

La proposition juridiquement pertinente est différente et plus solide : une adresse IP est un identifiant en ligne susceptible de concerner une personne identifiable lorsqu'il existe des moyens raisonnables de rattachement. La Cour de justice de l'Union européenne l'a jugé pour une adresse IP dynamique lorsque le responsable dispose de moyens légaux lui permettant d'obtenir les informations complémentaires du fournisseur d'accès. Le considérant 30 du RGPD précise également que les adresses IP et autres identifiants en ligne, combinés aux informations reçues par les serveurs, peuvent laisser des traces utilisables pour créer des profils et identifier des personnes.

Un préfixe /24 est moins précis qu'une adresse complète : il désigne normalement un ensemble pouvant contenir jusqu'à 256 adresses IPv4. Mais, associé au User-Agent, à l'heure, à la requête et aux informations auxiliaires du destinataire, il participe à une empreinte beaucoup plus étroite. Le résultat de 79,33 % publié par Microsoft Research sur les journaux Bing en apporte précisément la démonstration empirique pour le couple User-Agent + /24.

13.2.2. Ajouter des quasi-identifiants provenant de l'utilisateur va logiquement contre l'anonymat📋

Le raisonnement peut être exprimé simplement. Pour chaque attribut, on considère l'ensemble des hôtes compatibles avec l'observation :

H(IP /24 + User-Agent + heure + requête)
  = H(IP /24)
  ∩ H(User-Agent)
  ∩ H(heure)
  ∩ H(requête)

L'intersection ne peut pas contenir davantage de candidats que chacun des ensembles pris séparément. En l'absence d'une véritable opération d'anonymisation — par exemple agrégation suffisante, bruit, suppression de granularité ou autre garantie démontrée — ajouter au flux des attributs bruts ou stables provenant de l'utilisateur préserve ou réduit l'ensemble des hôtes possibles. Cela augmente, ou à tout le moins maintient, les capacités d'individualisation et de corrélation du destinataire.

C'est une conséquence logique, et non une simple impression : transmettre à Bing IP /24 + User-Agent ne peut pas être présenté comme un acte d'anonymisation. Ces deux données forment au contraire une empreinte d'hôte dont Microsoft avait lui-même mesuré le pouvoir distinctif sur ses propres journaux. Si Qwant ajoutait ces informations aux requêtes envoyées à Bing ou Bing Ads, cet ajout allait, par définition, dans le sens de la distinction et de la corrélation de l'utilisateur ou de son terminal, donc à l'encontre de la promesse d'anonymat.

Cette conclusion n'implique pas que toute donnée supplémentaire diminue toujours l'anonymat : une donnée délibérément agrégée, bruitée ou transformée peut participer à une anonymisation robuste. Elle vise ici la transmission de quasi-identifiants individualisants — préfixe IP, User-Agent, heure, requête ou identifiant stable — sans démonstration d'un procédé rendant négligeable la ré-identification par le destinataire et avec ses propres données.

Qwant a d'ailleurs modifié publiquement son vocabulaire en octobre 2020, après ses échanges avec la CNIL et ses experts, pour déclarer qu'il était « plus juste » de parler de données pseudonymisées. Cette correction postérieure ne détermine pas rétroactivement chaque détail technique du flux de 2016, mais elle confirme que la présentation antérieure en termes d'anonymisation était trop catégorique.

13.3. Avis 05/2014 du G29 : le document WP216📋

La référence parfois abrégée « WP14 » doit être désignée précisément comme l'avis 05/2014 du groupe de travail « Article 29 » sur les techniques d'anonymisation↗ (ouvre dans une nouvelle fenêtre), adopté le 10 avril 2014 et enregistré sous le numéro WP216.

Cet avis était donc disponible plus de deux ans avant les tweets d'août 2016 et l'échange interne de décembre 2016. Il posait déjà plusieurs principes essentiels :

• l'anonymisation doit empêcher de façon irréversible l'identification par les moyens susceptibles d'être raisonnablement employés par le responsable du traitement ou par un tiers ;
• la pseudonymisation n'est pas une anonymisation, mais une mesure de sécurité réduisant la corrélation avec l'identité d'origine ;
• retirer ou remplacer un identifiant ne suffit pas si des quasi-identifiants permettent encore de distinguer ou de relier les enregistrements ;
• une généralisation — rendre une valeur moins précise — ne protège pas automatiquement contre la corrélation et l'inférence ;
• le contexte importe, notamment les autres données détenues par le destinataire et les possibilités de croisement avec d'autres jeux ;
• l'analyse doit évoluer avec la puissance de calcul, les outils disponibles et les nouvelles connaissances.

Le G29 propose trois tests cumulatifs pour apprécier la robustesse d'un procédé :

1. individualisation : peut-on isoler les données correspondant à une personne ou à un même sujet ?
2. corrélation : peut-on relier plusieurs enregistrements d'un même sujet, dans le même jeu ou entre plusieurs jeux ?
3. inférence : peut-on déduire une information concernant ce sujet à partir des attributs disponibles ?

Appliquée au problème soulevé dans T1 et T2, cette grille interdit de raisonner sur le seul champ IP. La question pertinente n'est pas seulement :

« Le dernier octet a-t-il été supprimé ? »

mais :

« Le préfixe restant, combiné à la requête, à l'heure, au User-Agent, à un cookie, à un identifiant publicitaire ou aux données déjà détenues par Bing, permet-il encore d'individualiser ou de corréler un utilisateur ou son terminal par des moyens raisonnables ? »

L'article NDSS de 2012 apportait déjà un exemple empirique de cette corrélation. L'avis WP216 lui donnait, en 2014, une grille d'analyse européenne : une réduction de précision peut être une mesure de minimisation ou de pseudonymisation utile sans produire, à elle seule, des données anonymes.

13.4. CNIL 2019-2025 : corroboration institutionnelle ultérieure dans le dossier Qwant📋

Il faut distinguer la date de la règle de celle de la constatation institutionnelle ultérieure. La notice publique de la CNIL relative à Qwant↗ (ouvre dans une nouvelle fenêtre), publiée en 2025, précise que la CNIL avait qualifié les données de personnelles et non anonymes dès 2019, après des analyses conduites au regard des recommandations et jurisprudences pertinentes à l'époque des faits. Elle constitue donc une corroboration institutionnelle ultérieure du problème de qualification pour le traitement Qwant-Microsoft examiné en 2019. Elle n'est ni un audit du code historique de 2016, ni la preuve qu'une analyse Qwant appliquant alors les critères de WP216 aurait existé.

Cette corroboration n'importe pas dans l'année 2016 une règle née en 2025. La règle et la méthode étaient antérieures : l'article 2 de la loi Informatique et Libertés dans sa version en vigueur en 2016↗ (ouvre dans une nouvelle fenêtre) imposait déjà de tenir compte de l'identification indirecte et des moyens accessibles à toute autre personne ; WP216, adopté en 2014, explicitait déjà les critères d'individualisation, de corrélation et d'inférence.

Les PV et annexes biffés OCR et les documents de plainte biffés OCR rendent la continuité technique visible : la CNIL a copié search_ads.php, des configurations d'en-têtes et des extraits ; Qwant lui a décrit l'AUID comme un hash de l'adresse IP complète et du User-Agent ; un courrier du dossier applique expressément à Qwant les trois critères de WP216 et exige une étude du risque de ré-identification avant de pouvoir parler d'anonymisation. La notice publique de 2025 confirme ensuite la conclusion : les données transmises à Microsoft étaient pseudonymisées, non anonymes.

L'OCR distingue deux mécanismes qu'il ne faut pas fusionner : search_ads.php transmettait à Bing Ads une IPv4 tronquée au /24 avec le User-Agent, tandis que l'AUID contrôlé en 2019 était décrit comme un hash SHA-256 de l'IP complète et du User-Agent, avec un sel renouvelé tous les 90 jours.

L'AUID n'était donc pas une donnée directement identifiante, mais une donnée personnelle indirectement identifiante (DPI). Cette précision ne le fait pas sortir de la catégorie juridique des données personnelles : une DPI reste une donnée personnelle et relève ici de la pseudonymisation.

Il établit surtout une rupture chronologique :

1. le 15 novembre 2019, Qwant conteste encore la qualification personnelle de l'AUID, tandis que la CNIL retient son caractère indirectement identifiant, et décrit les positions comme « plutôt tranchées » ;
2. le 6 février 2020, Qwant invoque la volonté de sa « nouvelle gouvernance » de répondre aux observations ;
3. le 16 octobre 2020, le nouveau président rattache explicitement la réévaluation intégrale de la politique et la prise en compte des contrôles CNIL au profond renouvellement de la gouvernance ;
4. les 20 et 22 octobre 2020, Qwant transmet les documents de régularisation puis annonce la mise en ligne de la politique révisée.

Il serait donc inexact d'écrire que Qwant avait suivi la qualification de la CNIL dès les contrôles de 2019. Les pièces montrent au contraire que l'ancienne gouvernance maintenait une position opposée et que la décision déclarée de s'aligner intervient après son remplacement.

Les autres publications de 2025 montrent parallèlement que le problème soulevé n'a pas été invalidé par l'évolution technique et que la même méthode générale demeure employée.

Dans sa page Nouvelles méthodes de traçage en ligne : quelles solutions pour se protéger ?↗ (ouvre dans une nouvelle fenêtre), mise à jour le 10 février 2025, la CNIL classe l'utilisation de l'adresse IP parmi les techniques permettant de reconstituer l'historique d'un internaute, aux côtés de l'empreinte numérique, des liens uniques et des identifiants persistants.

Dans son projet de recommandation de 2025 relatif aux traitements de données de localisation des véhicules connectés↗ (ouvre dans une nouvelle fenêtre), la CNIL reprend explicitement l'avis WP216 et énonce une méthode plus opérationnelle :

• le caractère anonyme doit être démontré par une analyse concluant à un risque de ré-identification négligeable ;
• à défaut, les données demeurent personnelles ;
• la suppression des identités ou le chiffrement partiel de certains attributs ne garantit généralement pas l'anonymat ;
• les mesures de sécurité, d'organisation ou les garanties contractuelles ne remplacent pas une technique d'anonymisation ;
• l'analyse doit étudier les attaques décrites dans la littérature scientifique, leurs facteurs de succès et les moyens raisonnablement accessibles à un attaquant ;
• les résultats doivent être documentés et réévalués à mesure qu'apparaissent de nouvelles attaques et connaissances.

Ce texte porte principalement sur la localisation automobile. Ses exemples de trajectoires ne sont donc pas directement transposables à des journaux de requêtes web. Sa méthode générale est néanmoins pertinente : une affirmation d'anonymat ne se déduit ni du nom donné au procédé, ni de la seule suppression d'un attribut. Elle résulte d'une évaluation contextualisée du jeu complet, du destinataire et de ses capacités de corrélation.

13.5. Ce qui appartenait déjà à l'état de l'art en 2016📋

En août et décembre 2016, il était déjà publiquement établi que :

• des attributs apparemment ordinaires deviennent fortement distinctifs lorsqu'ils sont combinés ;
• le User-Agent et un préfixe IP /24 pouvaient permettre un suivi précis d'hôtes dans des journaux Bing ;
• supprimer le dernier octet d'une IPv4 constituait une généralisation, pas une preuve d'anonymisation ;
• la pseudonymisation laissait subsister les risques d'individualisation, de corrélation et d'inférence ;
• Microsoft avait lui-même quantifié ce pouvoir de suivi sur ses journaux et commercialisait des API fondées sur la transmission de catégories d'attributs comparables ;
• l'évaluation devait prendre en compte les informations accessibles au destinataire, et non uniquement celles conservées par l'émetteur.

Il serait donc excessif d'affirmer que T1 et T2 formulaient en 2016 une crainte purement spéculative ou inconnue de l'état de l'art. Leur intuition centrale était soutenue à la fois par une publication scientifique de 2012 directement fondée sur Bing et par la doctrine européenne de 2014.

Inversement, cet état de l'art ne permet pas de sauter de la possibilité technique à la preuve factuelle. Pour conclure sur le flux Qwant-Bing, il reste nécessaire d'établir :

• les champs réellement transmis avec chaque requête ;
• leur granularité et leur stabilité ;
• la présence éventuelle d'un User-Agent, cookie, identifiant ou horodatage ;
• les journaux et autres données dont Microsoft/Bing disposait ;
• les durées de conservation et les possibilités effectives de rapprochement ;
• l'existence éventuelle d'opérations réelles de suivi ou de ré-identification.

La conclusion technique proportionnée est donc :

En 2016, la littérature scientifique et la doctrine européenne suffisaient déjà à exclure qu'une adresse IPv4 privée de son seul dernier octet puisse être réputée anonyme par principe. Combiné à d'autres attributs, son préfixe /24 conservait un pouvoir démontré d'individualisation et de suivi. Cela rendait l'alerte techniquement sérieuse et vérifiable, sans prouver à lui seul le contenu exact du flux Qwant-Bing ni une ré-identification effectivement accomplie.

14. Chapitre XI - Cadre juridique à la date des faits📋

14.1. Les tweets d'août 2016📋

À cette date, l'article L. 1132-3-3 du Code du travail protégeait déjà le salarié contre une sanction ou une discrimination pour avoir relaté ou témoigné, de bonne foi, de faits constitutifs d'un crime ou d'un délit connus dans l'exercice de ses fonctions.

Les captures T1 et T2 montrent une préoccupation technique générale. Pour décider si elles entraient dans ce régime, il faudrait notamment apprécier :

• leur rattachement à des faits connus professionnellement ;
• la qualification potentiellement pénale des faits visés ;
• la bonne foi ;
• leur articulation avec d'autres messages ou signalements ;
• le motif exact d'une éventuelle sanction.

Le sous-dossier ne contient pas les actes disciplinaires nécessaires à cette analyse causale. Il documente le contenu des tweets, pas à lui seul leur qualification juridique définitive.

14.2. L'échange interne du 19 décembre 2016📋

La loi Sapin II du 9 décembre 2016 était entrée en vigueur le 11 décembre. Sa version initiale définissait le lanceur d'alerte et prévoyait un premier signalement au supérieur hiérarchique, direct ou indirect, à l'employeur ou à un référent désigné.

L'échange Skype présente plusieurs indices compatibles avec une alerte :

• un intérêt général lié aux données des utilisateurs ;
• une connaissance personnelle revendiquée de la production ;
• un signalement à une juriste interne chargée de conformité CNIL ;
• un problème exposé de manière précise ;
• un ton nuancé et contradictoire, plutôt qu'une simple invective.

Mais les captures ne prouvent pas toutes les conditions juridiques alors applicables :

• le caractère grave et manifeste d'une violation ;
• l'éventuelle qualification de crime ou délit ;
• le désintéressement au sens de la loi de 2016 ;
• la désignation de la destinataire comme référente ;
• la totalité des démarches internes et de leurs suites.

La qualification la plus prudente est donc :

signalement interne documenté sur la transparence et le traitement de données personnelles, présentant des caractéristiques d'une alerte professionnelle, sans que les dix captures suffisent seules à faire reconnaître judiciairement la qualité de lanceur d'alerte revendiquée.

14.3. Le RGPD📋

Le RGPD avait été adopté et était entré en vigueur en 2016, mais son article 99 a fixé son applicabilité au 25 mai 2018. Il est donc inexact de présenter sans nuance le dialogue de décembre 2016 comme le signalement d'une « violation du RGPD » déjà applicable.

La formulation correcte est :

« alerte interne de 2016 sur des traitements de données personnelles, appréciables alors notamment au regard de la loi Informatique et Libertés et de la doctrine européenne sur l'anonymisation, dans un contexte de préparation à l'applicabilité du RGPD. »

Le règlement confirmait déjà, dans son considérant 26, que les données pseudonymisées pouvant être réattribuées à une personne au moyen d'informations supplémentaires devaient être regardées comme concernant une personne identifiable.

14.4. De la contradiction technique à la qualification commerciale📋

La confidentialité et l'absence de traçage constituaient des caractéristiques mises en avant dans la présentation du service Qwant. Si une entreprise affirme commercialement que les données envoyées à son partenaire sont « anonymes » alors que les attributs transmis permettent raisonnablement l'individualisation et la corrélation décrites ci-dessus, la contradiction ne relève pas seulement d'une imprécision de vocabulaire technique.

Dans sa version applicable à compter du 1er juillet 2016, l'article L. 121-2 du Code de la consommation qualifiait notamment de trompeuse une pratique commerciale reposant sur des allégations, indications ou présentations fausses ou de nature à induire en erreur portant sur les caractéristiques essentielles du service ou sur la portée des engagements de l'annonceur. Sous réserve d'établir le contenu exact du flux, la matérialité des affirmations publiques, leur rôle dans la présentation commerciale du service et leur aptitude à tromper le consommateur, la qualification juridiquement la plus directement pertinente est donc celle de pratique commerciale trompeuse.

Le terme courant d'« escroquerie commerciale » exprime l'idée d'une promesse de confidentialité utilisée comme argument commercial alors que son émetteur saurait qu'elle est techniquement fausse. Il ne doit cependant pas être présenté dans ce document comme une infraction déjà établie. L'escroquerie, au sens de l'article 313-1 du Code pénal, suppose de prouver des éléments supplémentaires : l'emploi d'un faux nom ou d'une fausse qualité, l'abus d'une qualité vraie ou des manœuvres frauduleuses ; une tromperie intentionnelle ; puis une remise, la fourniture d'un service ou le consentement à un acte, obtenus par cette tromperie et causant un préjudice.

Le corpus permet ainsi de soutenir les propositions graduées suivantes :

1. constat technique : IP /24 + User-Agent permet l'individualisation et la corrélation d'un hôte ; ce couple n'est donc pas anonyme par nature ;
2. contradiction documentaire : si Qwant transmettait ce couple tout en affirmant que les informations remises à Microsoft étaient anonymes, la présentation publique était matériellement contradictoire avec le fonctionnement documenté ;
3. qualification commerciale à examiner : si cette promesse constituait un argument commercial susceptible d'influencer l'utilisateur, une pratique commerciale trompeuse peut être juridiquement caractérisée ;
4. qualification pénale non acquise par ces seules pièces : parler d'escroquerie comme d'un fait définitivement prouvé exigerait encore d'établir l'intention frauduleuse, les manœuvres, le lien causal, l'acte obtenu et le préjudice.

Cette gradation ne minimise pas le constat. Elle évite qu'une qualification pénale prématurée fragilise une démonstration technique et commerciale qui, elle, est directement étayée.

14.5. Ce que cette page ne tranche pas📋

Cette analyse ne statue pas sur :

• la légalité finale des traitements de Qwant en 2016 ;
• la validité d'une sanction disciplinaire ;
• la nullité d'un licenciement ;
• l'existence d'une représaille ;
• la responsabilité individuelle de la destinataire ;
• l'intention de Qwant ou de Microsoft ;
• l'existence d'une infraction pénale.

Ces questions exigent le rapprochement avec les actes disciplinaires, le code source, les politiques applicables, les décisions de la CNIL et les procédures judiciaires.

15. Chapitre XII - Grille probatoire finale📋

15.1. Faits directement établis par les dix fichiers📋

• T1 interroge la ré-identification à partir d'IP pseudo-anonymisées le 25 août 2016.
• T2 critique l'idée que retirer le dernier octet d'une IP suffirait à supprimer le risque.
• T1 et T2 ne nomment pas Qwant.
• T3 demande publiquement un contact à @MicrosoftAds.
• L'identifiant visible de T3 correspond au 26 août 2016 à 09:37 UTC.
• Une liste Google Drive affiche un fichier nommé compte microsoftads is a fake.PNG au 8 septembre 2016.
• Le 19 décembre, une conversation interne porte sur Bing, les CGU, la FAQ, l'adresse IP, les requêtes, les publicités et la production.
• J'y affirme avoir vu partir des informations en production.
• L'interlocutrice admet au moins l'envoi de la requête et de sa provenance.
• Le profil LinkedIn de l'interlocutrice la présente comme Legal Officer de Qwant avec une mission de conformité CNIL.

15.2. Faits directement établis par l'historique Git communiqué📋

• search_ads.php est ajouté le 17 juin 2016 au chemin www/application/models/search/search_ads.php.
• Le code construit une URL Bing Ads contenant les mots-clés dans le paramètre q.
• Il recopie le User-Agent de l'utilisateur dans l'appel sortant.
• Il transmet un en-tête X-Search-ClientIP.
• La fonction anonymizeIp() remplace seulement le dernier octet d'une IPv4 par 0 et conserve donc le préfixe /24.
• La même fonction renvoie sans transformation une chaîne ne contenant aucun point, notamment une adresse IPv6 écrite sous sa forme ordinaire.
• Le Referer est ajouté à l'appel Bing Ads le 21 juin 2016.
• Une version postérieure commente explicitement : Bing Ads required headers: Referer, IP address, User agent.
• Fin novembre, le code distingue l'IP complète, disponible dans l'application et utilisée pour un hash salé de test A/B, de l'IP IPv4 tronquée placée dans l'en-tête Bing.
• Le fichier est présent dans 127 tags, de v1.18.4 le 17 juin à v1.32.1 le 22 décembre 2016.

15.3. Déductions fortement soutenues📋

• T1 et T2 forment une même alerte technique sur les limites de la troncature d'adresse IP.
• @MicrosoftAds était vraisemblablement un compte non officiel.
• L'échange Skype constitue une notification interne précise d'un problème de transparence et de qualification des données.
• La destinataire était professionnellement pertinente pour recevoir ce signalement.
• Le désaccord portait moins sur l'absence de profilage par Qwant que sur ce qui était transmis à Bing et sur la manière dont les utilisateurs en étaient informés.
• La formulation de l'alerte comporte plusieurs marques de prudence et de bonne foi.

15.4. Points non établis par ce corpus seul📋

• La date exacte de T2.
• L'année 2016 à l'intérieur des seules images Skype.
• Le statut exact de @MicrosoftAds au jour de T3.
• La liste complète des données extérieures à search_ads.php éventuellement transmises à Bing en août ou décembre 2016.
• Le tag exact déployé sur chaque serveur et la date de chaque déploiement.
• Le nombre et la proportion de requêtes ayant effectivement emprunté ce chemin en production.
• Une ré-identification effective d'un utilisateur.
• La date exacte de modification de chaque FAQ ou CGU.
• La qualité formelle de DPO, CIL ou référente d'alerte de la destinataire.
• La réception de l'alerte par la direction ou par un supérieur hiérarchique.
• La suite donnée par Qwant.
• Le lien causal entre ces messages et une sanction.
• La réunion de toutes les conditions nécessaires à la reconnaissance judiciaire de la qualité de lanceur d'alerte revendiquée.

16. Conclusion📋

Ces dix pièces ne sont pas un dossier technique complet, mais elles forment une séquence documentaire cohérente.

En août 2016, l'alerte est publique, elliptique et prudente : elle questionne le risque de ré-identification et critique la confiance placée dans la seule troncature du dernier octet d'une adresse IP. Le tweet adressé à @MicrosoftAds ouvre un second sujet, celui du partenaire publicitaire, mais il vise vraisemblablement un compte non officiel et ne montre aucune démarche commerciale menée à son terme.

Cette préoccupation n'était pas spéculative. Microsoft Research avait lui-même mesuré sur les journaux Bing qu'un User-Agent combiné à un préfixe IPv4 /24 permettait de distinguer des hôtes avec une précision de 79,33 %, presque identique aux 80,62 % obtenus avec l'IP complète. Les spécifications commerciales de Bing organisaient par ailleurs la transmission et la persistance d'attributs permettant de localiser un terminal et de corréler ses requêtes.

Il n'est pas nécessaire de retrouver immédiatement un nom civil pour faire échouer l'anonymat : reconnaître le même hôte, relier ses recherches et rattacher ses adresses IP successives constitue déjà une individualisation et une corrélation. De même, ajouter à une requête le préfixe IP /24 et le User-Agent réduit logiquement l'ensemble des hôtes compatibles ; cela va dans le sens du fingerprinting, non dans celui de l'anonymisation. Dans ce contexte, qualifier par principe d'« anonymes » les données transmises à Microsoft ne pouvait être justifié par la seule suppression du dernier octet.

L'historique Git transforme ce rapprochement scientifique en preuve matérielle du code Qwant. search_ads.php programme précisément la combinaison étudiée : requête envoyée à Bing Ads, User-Agent d'origine, X-Search-ClientIP ramené au /24 pour une IPv4 et Referer. La fonction appelée anonymizeIp() ne réalise aucune autre anonymisation visible ; pour une chaîne sans point, elle retourne même l'entrée intacte. La présence du fichier dans 127 tags, avant, pendant et après l'alerte, montre qu'il ne s'agissait pas d'un fragment isolé sans intégration dans les versions étiquetées.

Le 19 décembre, l'alerte devient interne, détaillée et directement rattachée à Qwant. Elle porte sur :

• la présence de Bing dans les CGU et FAQ ;
• le caractère pseudonymisé plutôt qu'anonyme des informations ;
• ce qui était effectivement envoyé depuis la production ;
• l'accès de l'API à l'adresse IP ;
• l'envoi de la requête et de sa provenance ;
• la finalité Bing et publicitaire.

La conversation ne résout pas le désaccord. C'est précisément sa valeur : elle prouve que le problème technique et éthique a été formulé en interne, auprès d'une juriste chargée de conformité CNIL, avec une référence explicite à ce qui avait été observé en production.

La conclusion ne doit être ni minimisée ni exagérée. Une promesse publique d'anonymat contredite par les caractéristiques du flux peut relever d'une pratique commerciale trompeuse si les conditions du Code de la consommation sont réunies. Le présent corpus ne suffit cependant pas, à lui seul, à établir tous les éléments constitutifs de l'escroquerie pénale :

Le corpus établit l'existence d'une alerte interne professionnelle sur les flux Qwant-Bing et sur la confusion entre pseudonymisation et anonymisation. Le code Git la corrobore directement : Qwant avait programmé l'envoi conjoint à Bing Ads de la requête, du User-Agent, du Referer et du préfixe IPv4 /24. Le host fingerprinting rend la contradiction techniquement objective : l'absence de nom civil n'empêche ni l'individualisation ni la corrélation, et l'ajout du couple IP /24 + User-Agent va logiquement contre une prétention à l'anonymat. Cela étaye l'examen d'une pratique commerciale trompeuse ; sans les journaux de déploiement et d'exécution, les pièces commerciales et intentionnelles, les actes disciplinaires et les éléments réglementaires complémentaires, le corpus ne démontre toutefois pas seul une représaille, une escroquerie pénale ou une autre qualification judiciaire définitive.

17. Sources officielles de cadrage📋

• Code du travail, article L. 1132-3-3, version en vigueur d'août 2016↗ (ouvre dans une nouvelle fenêtre)
• Loi Sapin II, article 6, version entrée en vigueur le 11 décembre 2016↗ (ouvre dans une nouvelle fenêtre)
• Loi Sapin II, article 8, version initiale sur le canal interne↗ (ouvre dans une nouvelle fenêtre)
• Code du travail, article L. 1132-3-3, version issue de la loi Sapin II↗ (ouvre dans une nouvelle fenêtre)
• RGPD, considérant 26 et article 99↗ (ouvre dans une nouvelle fenêtre)
• RGPD, considérant 30 sur les adresses IP et autres identifiants en ligne↗ (ouvre dans une nouvelle fenêtre)
• CJUE, 19 octobre 2016, Breyer, C-582/14 - communiqué officiel relatif aux adresses IP dynamiques↗ (ouvre dans une nouvelle fenêtre)
• Code de la consommation, article L. 121-2, version applicable au 1er juillet 2016↗ (ouvre dans une nouvelle fenêtre)
• Code pénal, article 313-1 relatif à l'escroquerie, version en vigueur depuis le 1er janvier 2002↗ (ouvre dans une nouvelle fenêtre)
• Avis 05/2014 du G29 sur les techniques d'anonymisation↗ (ouvre dans une nouvelle fenêtre)
• CNIL - L'anonymisation de données personnelles↗ (ouvre dans une nouvelle fenêtre)
• NDSS 2012 - Host Fingerprinting and Tracking on the Web: Privacy and Security Implications↗ (ouvre dans une nouvelle fenêtre)
• Microsoft Azure - Mise à disposition générale des Bing Search APIs v7↗ (ouvre dans une nouvelle fenêtre)
• Microsoft Learn - Attributs utilisateur du Bing Web Search SDK↗ (ouvre dans une nouvelle fenêtre)
• Microsoft Learn - Microsoft Advertising Conversions API↗ (ouvre dans une nouvelle fenêtre)
• CNIL - Nouvelles méthodes de traçage en ligne, mise à jour du 10 février 2025↗ (ouvre dans une nouvelle fenêtre)
• CNIL 2025 - Projet de recommandation relatif aux traitements de données de localisation des véhicules connectés↗ (ouvre dans une nouvelle fenêtre)
• CNIL - Qwant : traitement des données personnelles et rappel aux obligations légales, 11 février 2025↗ (ouvre dans une nouvelle fenêtre)

18. Articulation avec le reste du dossier📋

Cette page doit être lue avec :

• le contexte général du dossier Qwant ;
• le corpus des communications de Qwant sur l'anonymat et l'anonymisation ;
• l'index des pièces CNIL et CADA ;
• l'analyse de l'auto-identification de Qwant dans l'avertissement du 7 septembre 2016 ;
• la synthèse autonome de l'état de l'art, de NDSS 2012 à la CNIL en 2025.

Ces chapitres apportent des éléments postérieurs ou extérieurs aux dix captures ici étudiées. Parmi eux, les contrôles CNIL de 2019 et leur publication en 2025 corroborent ultérieurement le problème de qualification pour le traitement alors examiné, mais ils ne doivent être confondus ni avec ce que les captures établissent directement, ni avec un audit du code de 2016.